InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / 1991 / 91_016r.txt < prev next >

Wrap

Text File | 1991-05-05 | 30.0 KB | 890 lines

Network Working Group April 1991 Internet-Draft M.T. Rose Internet Draft CO/CL Interworking -- Introduction Apr 91 An Approach to CO/CL Interworking -- Part I: Introduction Wed Apr 17 09:12:55 1991 CO/CL Interworking Workshop July 24-26, 1990 April 5, 1991 M.T. Rose (editor) Performance Systems International, Inc. mrose@psi.com 1. Status of this Memo An approach to the OSI CO/CL Interworking problem is proposed. This approach has been developed at the request of the FNC and RARE communities, but may be applicable to other communities. This memo does not explicitly specify a standard, however, it may form the basis for policy within the FNC, RARE, or other communities. Distribution of this memo is unlimited. Questions should be directed to the editor. M.T. Rose (editor) [Page 1] Internet Draft CO/CL Interworking -- Introduction Apr 91 2. Introduction The OSI transport service[1] may be realized through a variety of transport/network protocol combinations. Regrettably, few of the combinations actually interoperate with each other. As such, even if all OSI-capable end-systems enjoyed full- connectivity, they would not be able to uniformly interoperate. This memo examines the problem and proposes an approach in order to develop solutions to this problem. In particular, the short-term focus of this work draws on early experience in the area of both OSI realization and transition and coexistence between OSI and the Internet suite of protocols. In contrast, the long-term focus of this work utilizes a mature OSI infrastructure. This memo begins by introducing a model of a "pure" OSI end- system and how it establishes a transport connection to another end-system. Next, the practical problems of realizing this model are presented. Following this, a two-phase approach towards a solution is examined. Finally, the implications of that solution are explored. The reader is assumed to have a basic familiarity with the OSI end-to-end services. 2.1. An Aside This memo deals with the OSI transport service. A fundamental assumption of the presentation is that the two end-systems are attempting to interoperate using a common application protocol, e.g., the OSI Directory (X.500). This memo is explicitly uninterested in the problem of achieving interoperability between two end-systems using different application protocols, e.g., one end-system using the OSI file service (FTAM) and the other end-system using the Internet file transfer protocol (FTP). In this case, an application gateway technology should be used. In brief, this memo is interested only in environments in which the application is identical on both end-systems. M.T. Rose (editor) [Page 2] Internet Draft CO/CL Interworking -- Introduction Apr 91 3. Application Use of End-to-End Services This section introduces a conceptual model as to how OSI transport connections might be established. When an OSI application wishes to establish an association, that application identifies an application entity that provides the service desired for communication. The application entity identification is given to the OSI Directory and the corresponding presentation address is retrieved. This presentation address consists of a presentation selector, session selector, and a transport address. When the association is to be initiated, there are two parameters of interest to us: the presentation address as provided by the Directory, and the communications quality-of- service (QoS) as desired by the application. The first identifies the location of the desired service, the second identifies the characteristics of the association to be established with that service. After passing through the highest layers, the transport address, consisting of a transport selector and one or more network addresses, is given to the transport service, and a request is made to establish a transport connection. The local transport entity now follows three steps in order to establish the connection: (1) The entity looks at each network address and decides which mode of network service, connection-oriented (CONS) [2] or connectionless-mode (CLNS) [3], will be used for the address. At present, there is no standard method nor set of agreements for making this determination; in some implementations, the determination is made on the basis of NSAP prefixes, with this information being configured by the system administrator. Based on the derived network service and the desired QoS, the local transport entity selects a transport protocol. That is, for each network address in the transport address, the entity selects a combination of a transport protocol and network service, referred to as a TS-stack, that will be used to establish a transport connection to that address. M.T. Rose (editor) [Page 3] Internet Draft CO/CL Interworking -- Introduction Apr 91 (2) The network addresses are then ordered, based on the desired QoS and the "closeness" of the network address. Again, this decision is a local matter. Suppose, for example, a transport address contained two network addresses, each implying use of a CONS. One of the network addresses might reside in a private network, whilst the other address resides in a public data network. For economic reasons, the local transport entity might prefer to try the private network first. (3) For each network address, the local transport entity starts the protocol machine for the TS-stack associated with that address. This results in a transport protocol and underlying network service being invoked. Once a transport connection is established, the remaining network addresses are ignored. 3.1. Emulation of OSI End-to-End Services It should be noted that a TS-stack can be realized using non- OSI protocols. For example, the RFC1006 method defines a transport service convergence protocol which smoothes over the differences in the services offered by the OSI transport service and the TCP [4]. This is known as the RFC1006/TCP TS-stack. If such a protocol is properly defined, then the OSI upper- layer infrastructure (session, presentation, and application) running above is unable to tell that it is not running in a "pure" OSI environment. Of course, one must also have a means for storing such addresses in the OSI Directory. Kille has defined an Interim approach[5], which, among other things, allows addresses associated with the RFC1006/TCP TS-stack to be encoded as real OSI network addresses. Using such an approach, these addresses may be transparently stored in the OSI Directory. Further, one can easily examine such an address and determine the appropriate TS-stack to use when initiating a connection. The use of the RFC1006 method is particularly interesting as it allows use of the powerful OSI applications on the stable end-to-end services offered by the Internet suite of M.T. Rose (editor) [Page 4] Internet Draft CO/CL Interworking -- Introduction Apr 91 protocols. M.T. Rose (editor) [Page 5] Internet Draft CO/CL Interworking -- Introduction Apr 91 4. Problems in Realizing the Model This memo is concerned with one class of problem which might arise as the local transport entity acts as described above. Looking back at the first step, the entity must establish a binding between each network address and a TS-stack. Suppose that the end-system on which the transport entity resides offers only a subset of the TS-stacks implied by the transport address. For example, suppose that there are four network addresses, two requiring use of the CONS, and the other two requiring use of the CLNS. If initiating end-system supports only the CONS, then any network address which requires use of the CLNS can not be reached from that end- system. That is, the local transport entity must intersect TS-stacks derived for the network addresses with the TS-stacks supported by the local end-system. Thus, in this first step, only a subset of the network addresses may be suitable for use on the initiating end-system. The problem, of course, is that the intersecting subset may be empty! From a "purist" perspective, interworking can not occur in this case, and the local transport entity will immediately generate a transport disconnect. In exploring this problem, it is natural to ask how often this situation arises. The answer is simple: in a homogeneous OSI environment, say a CL-mode LAN (e.g., an 8802 network) or a CO-mode WAN (e.g., an X.25 network), this problem should never arise. However, whenever different OSI environments are interconnected, this problem usually results. Consider the simplest example: a site has an 8802-based subnetwork running CLNP, TP4, and OSI applications. All of the end-systems in that environment implement the TP4/CLNS TS-stack. Some time later, one of the end-systems on that subnetwork is attached to an X.25-based subnetwork. For brevity, term this end-system "dual". On the dual end-system, another TS-stack is added, e.g., TP0/CONS. The other end- systems are not modified since they continue to have a single point of attachement, which supports only the CLNS. Now, observe that within the original 8802-based subnetwork, all end-systems, including dual, continue to interoperate with one another. Also observe that the dual end-system can interoperate with any other end-system directly attached to M.T. Rose (editor) [Page 6] Internet Draft CO/CL Interworking -- Introduction Apr 91 the X.25-based subnetwork. However, note that it is unlikely that any of the other end-systems in the 8802-based subnetwork can interoperate with an arbitrarily chosen end-system in the X.25-based subnetwork. In order to appreciate the basis for the approach which follows, it is necessary to introduce one additional term, the OSI community. An OSI community is a collection of end- systems connected together and sharing a common TS-stack. That is, more technically, a community is defined in terms of connectivity and a TS-stack. So, given two OSI communities which have an intermediate- system in common, but have different TS-stacks, can arbitrary end-systems in those two communities interoperate? First, note that the CONS and the CLNS do not interwork. Hence, if the two communities support only different modes of network service, then they can not interoperate. Second, note that even if two communities share a network mode in common, then all intermediate-systems must also support that same network mode. For situations in which direct interworking is not possible, a transport-layer relaying approach has been suggested. Because they exist outside the scope of OSI, the theory and practice of transport-layer relays are poorly-understood. M.T. Rose (editor) [Page 7] Internet Draft CO/CL Interworking -- Introduction Apr 91 5. Transport-Service Bridges The motivation behind transport-layer relaying is to observe that all TS-stacks share one thing in common: they all offer the OSI transport service. Thus, a new entity is introduced, residing above the transport service, termed a transport service bridge (or TS-bridge), or CO/CL-gateway. The TS- bridge is purposefully naive as to TS-stacks or the transport protocols and network services which compose them. Rather, the TS-bridge knows only how to invoke the OSI transport service, which is offered by all TS-stacks, regardless of their composition. In pictorial form: +------------------------------------+ | | | | | +----------------------------+ | | | TS-bridge | | | +----------------------------+ | | | | | | | | | | | | | +----------+ | +----------+ +----------+ | +----------+ | | | | | | | | | | | TS-stack | | | TS-stack | | TS-stack | | | TS-stack | | #1 | | | #1 | | #2 | | | #2 | | | | | | | | | | | +----------+ | +----------+ +----------+ | +----------+ | | | | | | | | | | | | | +------------------------------------+ | | | | | | | | | +------------------+ +------------------+ The function of the TS-bridge is simple: upon receiving a transport connection indication (a T-CONNECT.INDICATION primitive), the TS-bridge initiates a second transport connection, to the actual destination address. If the second connection is established, then the TS-bridge accepts the first transport connection. From this point on, any data received on one transport connection is simply sent on the M.T. Rose (editor) [Page 8] Internet Draft CO/CL Interworking -- Introduction Apr 91 other transport connection. When a disconnect occurs on one of the transport connections, the TS-bridge disconnects the other transport connection. Of course, if the second connection is not established, then the TS-bridge will simply disconnect the first transport connection. 5.1. State Machine The TS-bridge starts in the IDLE state. The events and actions below refer to the service primitives defined in [1]. Further, "A" refers to the initial transport connection, and "B" refers to the second transport connection. STATE EVENT --> ACTION GOTO ----- -------------------- -------------------- ---- IDLE A: T-CONNECT.IND B: T-CONNECT.REQ WAIT WAIT B: T-CONNECT.CNF A: T-CONNECT.RSP DATA WAIT B: T-DISCONNECT.IND A: T-DISCONNECT.REQ IDLE WAIT A: T-DISCONNECT.IND B: T-DISCONNECT.REQ IDLE DATA A: T-DATA.IND B: T-DATA.REQ DATA DATA B: T-DATA.IND A: T-DATA.REQ DATA DATA A: T-EXP-DATA.IND B: T-EXP-DATA.REQ DATA DATA B: T-EXP-DATA.IND A: T-EXP-DATA.REQ DATA DATA B: T-DISCONNECT.IND A: T-DISCONNECT.REQ IDLE DATA A: T-DISCONNECT.IND B: T-DISCONNECT.REQ IDLE Note that if any errors occur (e.g., interface errors), then both transport connections are disconnected. Note that the TS-bridge is bi-directional: an end-system in any community may initiate a connection to an end-system in a different community, providing that the TS-bridge is a member of both communities. 5.2. Parameters for the second connection There are a few other special interactions performed by the TS-bridge when establishing the second transport connection. These all affect the parameters given to the T-CONNECT.REQ M.T. Rose (editor) [Page 9] Internet Draft CO/CL Interworking -- Introduction Apr 91 primitive. (1) It should be noted that there are very slight differences in the total service offered by some TS-stacks. In particular, a TS-stack containing TP0 does not support user-data during connection establishment. As such, if the T-CONNECT.IND primitive for "A" contains user-data, then the TS-bridge disconnects the transport connection. Similarly, if the T-CONNECT.CNF primitive for "B" contains user-data, then the TS-bridge disconnects both transport connections. (2) In addition, a TS-stack containing TP0 does not support the expedited data facility. As such, the TS-bridge must be prepared to down-negotiate use of this facility. Basically, when forming the T-CONNECT.REQ primitive for "B", the TS-bridge copies the value of the expedited data facility parameter from the T-CONNECT.IND primitive for "A". Similarly, when forming the T-CONNECT.RSP primitive for "A", the TS-bridge copies the value of the expedited data facility parameter from the T-CONNECT.CNF for "B". 5.3. Impact of TS-bridges on End-Systems The explanation above did not indicate how a transport connection was redirected to a particular TS-bridge. Depending on the approach taken, varying levels of transparency can be achieved in the end-systems. One solution requires knowledge of the TS-bridge in the initiating end-system; further, such a solution requires that the initiating end-system act in a non-standard fashion in order to establish a connection when using a TS-bridge. In contrast, another solution might rely on a rich OSI network-layer infrastructure so as to achieve the "ES- transparency" effect: no local knowledge of TS-bridges should exist at an end-system; further, use of a TS-bridge should not result in non-standard behavior at an end-system. M.T. Rose (editor) [Page 10] Internet Draft CO/CL Interworking -- Introduction Apr 91 5.4. Impact of TS-bridges on the Transport Service It should be noted that transport-layer relays suffer from (at least) four weaknesses: (1) A transport-layer relay maintains state for its two existing connections, and is therefore a single point of failure. For example, if the relay fails, the transport connections between the end-systems will fail, even though both end-systems are operational and an alternative path is available. (2) Use of a transport-layer relay defeats the end-to-end integrity property of the TS-stack. Note that user-data passes through the relay in transit between the two TS- stacks. This data might be corrupted if the relay is faulty. Similarly, use of a transport-layer relay defeats any transport-level encrypt mechanisms as the data appears in the clear inside the relay. (Of course, encryption could occur at a higher layer to retain privacy.) (3) Use of a transport-layer relay may introduce additional variability in round-trip times due to buffering in the relay. (The implications of this effect are not known.) (4) Finally, depending on how use of the transport-layer relay is integrated with the end-systems, end-to-end addresses may not be carried transparently. For example, in the short-term, the responding end-system sees the network address of the transport-layer relay as the calling address, instead of the address of the actual originator. M.T. Rose (editor) [Page 11] Internet Draft CO/CL Interworking -- Introduction Apr 91 6. Towards a Solution In the best solution, there is a single mode of OSI network service which is truly ubiquitous. In this case, a single community exists and interworking is achieved through the use of network-layer relays. In preparation for this long-term scenario, technology must be identified and perhaps incrementally advanced to promote a homogeneous network service. In the meantime, a large TCP/IP-based community exists and a TP0/CONS community is growing. Some interworking requirements exist today and these requirements are expected to increase. This suggests a short-term solution to address immediate requirements, an intermediate-term solution applicable as the TP0/CONS community grows large, and a long- term solution applicable once two large OSI communities, one CO-mode and the other CL-mode, exist and have interworking requirements. Thus, an approach towards the solution consists of two parts, and two companion memos have been been written, each corresponding to the short-term and long-term: In the short-term, one must rely on TS-bridges to provide connectivity between non-internetworking communities. The first companion memo, [6], describes the operation of TS- bridges in such an environment. The fundamental component of the long-term is the use of network-layer relays, supporting either the CO- or CL-mode OSI network service. Use of network-layer relays is well- understood. However, even in the long-term, situations will arise in which both network services are required. In this case, TS-bridges are still necessary. The second companion memo, [7], describes the operation of TS-bridges in such an environment. M.T. Rose (editor) [Page 12] Internet Draft CO/CL Interworking -- Introduction Apr 91 7. Acknowledgements The first version of this memo was produced by the CO/CL Interworking Workshop, which met on July 24-26, 1990: Les Clyne, JNT Walid Dabbous, INRIA Phill Gross, NRI Christian Huitema, INRIA Steve Kille, UCL Kevin Mills, NIST Julian Onions, Nottingham University Marshall Rose, PSI Rachid Sijelmassi, NIST Mitchell Tasman, University of Wisconsin There were several contributions which led to the development of the approach described in this memo: In "CO-CL and TCP/IP Interworking and Coexistence", Mills suggested that the problem can be solved by using a single mode of network service (CLNS), and further that interoperability with TCP/IP-based environments would occur through the use of application gateways. In "A Survey of Solutions to the Connectionless/Connection- mode and the OSI/DoD Interworking Problems", West and Sijelmassi outlined the various approaches and assigned comparative metrics. The ISO/IEC Draft Technical Report 10172 (SC 6 N 5906) outlined a framework for transport-layer relaying. In "Implementation Agreements for Transport Service Bridges", Rose outlined the basic model of transport-layer relaying and proposed the basis for an approach in the short-term. In "An ISO TP4-TP0 Gateway", Landweber and Tasman described an implementation of a TS-bridge. In "An NSAP approach to build transport OSI transport bridges, Huitema and Dabbous described how ES-transparency can be achieved, and in "Extension of OSI TP4 to support transport bridging", they described modifications to the TP4 protocol to aid in achieving the ES-transparency effect. M.T. Rose (editor) [Page 13] Internet Draft CO/CL Interworking -- Introduction Apr 91 8. References [1] International Organization for Standardization. Information Processing Systems--Open Systems Interconnection--Transport Service Definition. International Standard 8072. (June, 1986). [2] International Organization for Standardization. Information Processing Systems--Data Communications-- Network Service Definition. International Standard 8348. (April, 1987). [3] International Organization for Standardization. Information Processing Systems--Data Communications-- Network Service Definition--Addendum 1: Connectionless- mode Transmission. International Standard 8348/AD 1. (April, 1987). [4] M.T. Rose and D.E. Cass. ISO Transport Services on top of the TCP. Internet Working Group Request for Comments 1006. Network Information Center, SRI International, Menlo Park, California, (May, 1987). [5] S.E. Kille. An interim approach to use of Network Addresses. Research Note RN/89/13. Department of Computer Science, University College London, (February, 1989). [6] M.T. Rose (editor). An Approach to CO/CL Interworking -- Part II: The Short-Term -- Conventions for Transport- Service Bridges in the absence of Internetworking, CO/CL Interworking Workshop, (July, 1990). [7] C. Huitema (editor). An Approach to CO/CL Interworking: -- Part III: The Long-Term -- Conventions for Network- Layer Relays and Transport-Service Bridges in the presence of Internetworking, CO/CL Interworking Workshop, (July, 1990). M.T. Rose (editor) [Page 14] Internet Draft CO/CL Interworking -- Introduction Apr 91 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 2.1 An Aside ............................................ 2 3 Application Use of End-to-End Services ................ 3 3.1 Emulation of OSI End-to-End Services ................ 4 4 Problems in Realizing the Model ....................... 6 5 Transport-Service Bridges ............................. 8 5.1 State Machine ....................................... 9 5.2 Parameters for the second connection ................ 9 5.3 Impact of TS-bridges on End-Systems ................. 10 5.4 Impact of TS-bridges on the Transport Service ....... 11 6 Towards a Solution .................................... 12 7 Acknowledgements ...................................... 13 8 References ............................................ 14 M.T. Rose (editor) [Page 15] ------- End of Forwarded Message